The Administration application is a default Cumulocity application that serves as the central management console for platform administrators. It is used to govern a tenant by managing users, roles, and permissions, subscribing to and managing applications and microservices, and configuring tenant-level settings such as retention rules, custom properties, and branding.
An alarm is a specific type of event that indicates a situation requiring user or system intervention. Unlike general events, alarms have a lifecycle status (ACTIVE, ACKNOWLEDGED, CLEARED) and a severity (CRITICAL, MAJOR, MINOR, WARNING), and are explicitly tracked within the platform until they are resolved.
The Analytics Builder is a tool in the Cumulocity Streaming Analytics application for designing real-time analytics models in a graphical, drag-and-drop environment. By combining pre-built blocks, you can quickly build model to transform streaming IoT data, generate new data, create alerts, or trigger device operations.
For details, see the Analytics Builder documentation.
Apama is the high-performance event processing engine that powers Cumulocity Streaming Analytics. It enables real-time data processing behind the scenes, forming the foundation for smart rules, Analytics Builder´s drag-and-drop models as well as custom EPL apps.
An application is a component integrated with the platform that delivers user interfaces (= web application), business logic (= microservice), or both, to enable, extend, or customize IoT solutions. Applications bridge device data with user workflows and business processes, supporting use cases such as remote monitoring, predictive maintenance, asset tracking, and smart automation. Cumulocity’s application enablement tools empower both business users and developers to build and deploy custom applications.
For details, see Application enablement in the documentation.
The application switcher is a UI component that shows all Cumulocity applications the user has access to and allows switching between these applications.
An asset is the digital representation of a business object within the Cumulocity inventory, such as a machine, building, or vehicle. Technically, an asset is a managed object that can be structured into a logical hierarchy (the asset hierarchy) using child asset relationships. Assets can take several forms: simple groups used for organization, devices that send telemetry data, or complex custom assets defined by an asset model in the Digital Twin Manager (DTM).
An asset hierarchy is a structure within the inventory that organizes assets (based on asset models) and devices to reflect their logical or business relationships, such as a factory containing production lines, which in turn contain individual machines. The asset hierarchy is built by nesting assets with one another to form parent-child relationships (child assets). It is fundamentally distinct from the communication hierarchy, which models the physical network topology (child devices).
An asset model is a reusable blueprint defined in the Digital Twin Manager (DTM) that specifies the structure, properties, and relationships of a particular type of asset. It includes a unique key and label, asset properties, and optionally references to child asset models to support the composition of asset hierarchies (for example, a wind turbine model composed of rotor and tower sub-models). Once published, an asset model governs how assets of that type are created, validated, and visualized across Cumulocity applications.
Asset properties are configurable attributes within an asset model that define, describe, and enrich an asset´s characteristics (for example, tower height in a wind turbine model). They can be of various data types, such as text, number, date, file, boolean, complex object, or custom. Properties may be simple (single values), complex (nested structures), or custom (additional metadata), and they act as reusable building blocks to ensure consistent data structures, metadata enrichment, and governed information across assets.
An audit log is a record of a security-relevant action performed on the platform. Audit logs are a special type of event that includes details about the user who performed the action, the application they used, the activity itself, and the severity. They provide a chronological and immutable trail of operations for security analysis and compliance auditing.
Authentication is the process of verifying the identity of a user, device, or application attempting to access the Cumulocity platform. Cumulocity supports multiple authentication methods, including basic authentication, OAI-Secure (an OAuth2-based implementation), and Single sign-on (SSO) integration with external identity providers.
Authorization is the process of determining whether an authenticated identity (user, device, or application) has the necessary permissions to access a specific resource or perform a particular action. Authorization in Cumulocity is managed through a Role-Based Access Control (RBAC) model, in which permissions are bundled into global roles and inventory role.
Availability refers to the monitoring of the connection status of a device to indicate whether it is ONLINE, OFFLINE, or its status is UNKNOWN. This status is determined by device communication patterns, such as the periodic sending of data or the maintenance of a push connection, and can be configured with a required interval using the c8y\_RequiredAvailability fragment.
Blocks are the basic processing units of a model. Each block implements some predefined functionality, such as receiving data from a sensor, performing a calculation, detecting a condition, or generating an output signal, and processes data accordingly. Each block has a number of inputs, outputs and configurable parameters. Analytics Builder comes with a set of prebuilt blocks, but can also be extended with custom blocks.
Branding is a feature, typically available in Enterprise tenants or the relevant add-ons, that enables organizations to customize the platform’s user interface to align with their corporate identity. This includes modifying logos, colors, fonts, and the application’s domain name to provide a consistent, customized user experience.
Bulk device registration is a method for registering larger quantities of devices into the Cumulocity platform by uploading a CSV file containing device details, rather than registering each device individually.
CCU (Cumulocity Compute Unit) is a standardized measure for computational resources consumed by custom microservices deployed by a customer. 1 CCU typically equates to 1 CPU core and 4 GiB of memory. CCUs are calculated based on daily average resource usage and used for billing purposes. The CCU calculation takes into account the resources denoted in the microservice manifest and the subscribed time for each microservice.
Change logs are the official record of Cumulocity product changes and announcements, published for all cloud deployments (Continous Deployment), detailing updates such as new features, improvements, and API changes or deprecations. Corresponds to the release notes in the Yearly releases.
Child assets denote a relationship type within the Cumulocity inventory’s domain model used to establish parent-child links between managed objects. This relationship forms the asset hierarchy, connecting a parent asset or group to its subordinate assets or devices from a business or logical perspective.
Child devices denote a relationship type within the Cumulocity inventory’s domain model used to establish parent-child links that reflect the communication hierarchy, connecting a parent device (often an agent or a gateway) to the downstream devices it manages.
The Cockpit application is one of the default applications of Cumulocity. It provides a self-service UI to manage and monitor IoT assets and data from a business perspective, like managing assets, visualizing data, working with dashboards and managing reports.
For details, see Cockpit in the documentation.
The communication hierarchy models how devices are connected to the platform from a network communication perspective. It is built using the child devices relationship, with agents or gateways typically forming the root of the hierarchy. This structure reflects the physical or network topology, as opposed to the logical business structure represented by the asset hierarchy.
The configuration management feature allows administrators and applications to remotely manage the settings of a device. This is typically achieved by creating and applying a configuration operation, often containing the c8y\_Configuration fragment with the desired configuration text or a reference to a configuration file stored as a binary.
The connection monitoring feature allows identifying devices that have stopped communicating with the Cumulocity platform. The connection status (ONLINE/OFFLINE) is determined by monitoring device heartbeats or tracking the status of a persistent push connection.
In the Cumulocity Continuous Deployment (CD) model, the different components of the Cumulocity platform are updated on a continuous basis. This means a frequent deployment of small incremental improvements. The changes are communicated via the change logs.
See also Private Preview, Public Preview and General Availability.
The Cumulocity CLI (Command Line Interface) is a software tool provided by Cumulocity that offers a command-line interface for interacting with the platform. It enables developers, administrators, and automation scripts to manage platform resources directly from a terminal. See also the CLI documentation.
Cumulocity Core is the foundation of the Cumulocity platform. It comprises all major components such as the default applications (Administration, Cockpit and Device Management), the Cumulocity operational store, microservices, security, REST API, MQTT API, and smart rules.
Cumulocity Datahub is a Cumulocity application for offloading a large amount of data from the Cumulocity operational store to a data lake and querying the data lake contents.
For details, see Analytics > DataHub in the documentation.
The Cumulocity Developer Codex is Cumulocity’s comprehensive design system aimed at developers building custom web applications. The Cumulocity Developer Codex provides a set of UI guidelines, a library of reusable Angular components (Web SDK), and styling utilities to ensure that custom applications maintain a consistent look and feel, and user experience with standard Cumulocity applications.
Cumulocity Edge is the onsite solution of Cumulocity intended to run as a local software application on industrial PC’s or local servers.
For details, see Edge in the documentation.
The Cumulocity OpenAPI Specification is a complete OpenAPI specification (following the OpenAPI 3.0 standard) for the Cumulocity REST API, available at https://cumulocity.com/api/. It describes the entire REST API, including available endpoints, operations on each endpoint, input and output for each operation, and authentication methods.
The Cumulocity operational store is an internal datastore where all data (such as alarms, events, inventory, and measurements) are stored in base collections.
The Cumulocity Sensor App is a free smartphone application for iOS and Android that turns a smartphone into a managed IoT device, enabling the real-time collection of sensor data from the phone, connected Bluetooth devices, and supported OBD sensors. It securely transmits this data to the Cumulocity platform and supports device registration, live data visualization, event and alarm triggering, and remote device operations, providing an easy entry point for exploring Cumulocity’s IoT capabilities.
For details, see Cumulocity Sensor App in the documentation.
The Cumulocity Streaming Analytics application allows users to add their own logic for the immediate, real-time processing of incoming data. Users can build Analytics Builder models or write custom EPL Apps to analyze data streams, generate new data, create alarms, or trigger operations on devices.
For details, see Analytics > Streaming Analytics in the documentation.
Dashboards are customizable views within applications like the Cockpit application, composed of various widgets, used to visualize data, monitor assets, and potentially trigger actions.
The data broker functionality is an optional feature in Enterprise tenants which lets you share data selectively with other tenants.
The data explorer is a visualization tool for exploring, comparing, and analyzing IoT data, such as measurements, alarms, and events, from specific assets or across all assets.
Data lakes are used in the context of Cumulocity DataHub. A data lake serves as a storage container for offloaded data, for example, ADLS Gen2/Azure Storage (Azure), S3 (Amazon), or a NAS.
A data point is a configuration that defines how a specific measurement time series is visualized in UI views like the data explorer and dashboards. Data points define how a measurement stream is displayed, including its label, color, unit, and threshold ranges. These settings can be customized in the UI or templated in the data point library.
The data point library provides a collection of templates used to standardize the visualization of measurement data across your account. Each template targets a specific measurement, identified by its fragment and series, and defines its visual properties (such as label, color, unit, threshold ranges). This ensures that all matching time series from any device are displayed consistently.
A device is a special type of asset that represents a physical piece of equipment connected to the Cumulocity platform. In the inventory, a device is represented as a managed object that is marked with the c8y\_IsDevice fragment, distinguishing it as an entity that can send data and receive operations.
Device agents are software components that translate a device-specific communication protocol into the standard Cumulocity REST or MQTT-based protocol, enabling secure, bi-directional communication. Device agents can be deployed on the device itself (for example, on a gateway) or run as server-side microservices within the Cumulocity platform.
The Device Management application is one of the default applications of Cumulocity. It provides functionalities for connecting, managing and monitoring devices and allows to control and troubleshoot devices remotely.
For details see Device Management application in the documentation.
A device protocol defines how data from a specific device type is transferred into the Cumulocity platform and translated into the Cumulocity data model.
The device replacement feature allows the replacement of physical devices without losing the historical data associated with the original device.
A digital twin is a virtual representation of a physical asset or system that is continuously updated with real-time IoT data from connected devices. This data-driven digital counterpart enables monitoring, analysis, and optimization of physical assets by combining sensor measurements with business context.
The Digital Twin Manager (DTM) is a schema-based modeling application in Cumulocity that enables users to create and manage data model schemas, which serve as blueprints for modeling assets, properties, and other managed objects, acting as reusable templates within the platform.
Cumulocity stores all operational data, such as managed objects, alarms, and measurements, as documents. A document is a versatile JSON structure with a unique identifier, allowing it to be referenced in URLs of web applications or REST APIs.
The domain model is the conceptual framework that defines how Cumulocity structures, represents, and relates different types of information (inventory, measurements, events, operations). Data is organized as modular fragments within JSON documents, allowing flexible extension and customization.
Edge Server is an informal term for Cumulocity Edge. See Cumulocity Edge.
An Enterprise tenant is a tenant type in the Cumulocity tenant hierarchy that provides advanced administrative capabilities, primarily focused on managing multiple subtenants. An Enterprise tenant (sometimes also referred as “parent” tenant) can create, manage, and bill its own subtenants and enables features like custom branding, custom domain names, and user hierarchies.
Apama EPL is a domain-specific, event-driven programming language with a syntax similar to Java, designed for writing programs that process events in realtime. In Cumulocity, EPL logic is typically implemented as EPL apps within the Streaming Analytics application.
EPL Apps is part of the Cumulocity Streaming Analytics application. It allows you to develop an EPL app directly within Cumulocity using Apama EPL, giving you a pro-code environment to define your streaming analytics applications.
A Cumulocity event is a time-stamped informational record that transmits real-time information on any state change of a device or asset. Next to Cumulocity events, the following types of events are used within the Cumulocity platform:
Export is a feature of the Cockpit application that allows users to extract a limited amount of platform data, such as measurements, alarms, or events, into CSV or XLSX files. Exports can be configured with filters for specific devices, time ranges, and data fields. The scheduling of recurring exports is a key function, managed by the report-agent microservice and configured within the Cockpit application.
Extensions are official or community-supported packages that add new functionalities to the Cumulocity platform. They can include plugins, which add features to existing applications at runtime, or blueprints, which are combinations of preconfigured UI functionalities for creating new applications.
Fragments are JSON objects used to extend Cumulocity’s core data types, such as managed objects, events, and operations. They are the primary mechanism for creating a flexible and extensible domain model, allowing the representation of any asset or device without a rigid, predefined database schema.
A conceptual, documented library of standard JSON structures (fragments) that define the platform’s data model for common device capabilities. It serves as a developer reference for building integrations.
In the Continuous Deployment model, General Availability (GA) refers to the availability of a feature to all customers (as compared to Private Preview and Public Preview). In the Yearly release model, General Availability (GA) refers to the general availability of a Yearly release. This is the stage where a feature is fully released and supported.
A type of role in Cumulocity’s permission model that contains permissions applying to all data within a tenant. Unlike inventory roles, which grant permissions to specific assets or groups, global roles apply tenant-wide.
A group is a special type of asset used to organize devices and other assets for structural and permission-management purposes. Groups support flexible organization and, when paired with inventory roles, can grant or restrict user access to the contained devices and assets.
The inventory stores all master data for devices and assets, including their configurations and relationships, and serves as the digital twin of physical or logical entities within Cumulocity.
Inventory roles contain permissions that grant access to specific groups of devices or assets in the inventory. They allow fine-grained authorization to particular assets or device groups and their associated data.
The isolation level defines how microservice instances are shared among tenants. Options are either “multi-tenant” (MULTI_TENANT in the manifest), where a single instance serves multiple subscribed tenants, or “per-tenant” (PER_TENANT in the manifest), where a dedicated instance is created for each subscribing tenant.
The location represents the geographical position of a managed object. The location is represented by the standard c8y\_Position fragment, which contains altitude, longitude, and latitude coordinates. Managed objects with this fragment can be displayed on Map widgets.
Maintenance releases are provided for supported Yearly releases and contain important bug fixes but no new features, ensuring stability and security for long-term supported versions of the platform.
Managed objects are the core building blocks of the Cumulocity inventory. A managed object is the primary digital record (digital twin) used to represent entities such as devices, assets, logical groupings, or application components. Managed objects are used to model data sources (for example, an IoT sensor), and all related data, such as events, alarms, and operations, is linked to the managed object. When referred to as a “source managed object”, it denotes the managed object representing the origin of that data.
The Management tenant builds the highest level in the Cumulocity 3-level tenant hierarchy, typically only available to the Operations team managing the Cumulocity instance. The Management tenant administers the entire platform deployment, including all Enterprise tenants, and holds exclusive platform-level administrative capabilities.
A measurement is a time-stamped reading or statistic collected from a sensor or device and linked to a source managed object. Measurements are organized into one or more fragments (for example, c8y_TemperatureMeasurement), each containing one or more series (for example, T) that hold a numeric value and a unit for specific observed properties.
Microfrontend refers to an architectural style for web applications where the UI is decomposed into smaller, independently deployable applications or plugins. Cumulocity’s web UI is built on this architecture with the Web SDK, allowing a “shell” application (like Cockpit) to be extended by loading “remote” modules (plugins) from other web applications.
Microservices are server-side applications that extend Cumulocity’s functionality, typically by implementing backend business logic or enabling integration with external systems. They are fully integrated into Cumulocity’s hosting, security, and API management, and can be designed to be highly available, scalable, and multi-tenant.
A microservice manifest is a required JSON file (cumulocity.json) included within a microservice package. It provides the necessary metadata for the platform to manage the microservice’s deployment, lifecycle, and integration.
The Cumulocity Microservice SDK is a set of tools, libraries, and documentation that helps developers build custom microservices efficiently. For Java, Cumulocity provides a dedicated SDK with Spring Boot integration. The SDK streamlines development by offering built-in authentication against the platform and robust context management, enabling secure, multi-tenant-aware applications. At the same time, microservices can be developed in any programming language, as long as they are packaged as Docker containers and comply with the platform’s requirements.
In Analytics Builder, a model is a visual representation of analytic logic created by connecting pre-built blocks via wires in a drag-and-drop environment. Each block performs a specific function, and together they form a workflow that can transform, analyze, and act on incoming data. A model can be designed as a reusable template model, which uses placeholders instead of fixed values. When you provide specific values for these placeholders, you create a runnable model instance.
Multi-tenancy is an architecture in which a single instance of a software application serves multiple customers (tenants). In Cumulocity, each tenant has a physically separated data space. Data sharing between tenants is disabled by default and must be explicitly configured (for example, using the data broker).
The navigator is an element on the left of the Cumulocity platform’s UI. It provides a list of menu items that direct you to various pages within the application currently in use.
An offloading pipeline is a configurable job within Cumulocity DataHub that defines the process of extracting data from a specific collection in the operational store, transforming it, and loading it into a target table within a data lake.
Operations are instructions sent to a device or asset to perform a specific action, such as control, configuration, or maintenance. Operations are linked to a source managed object, and are delivered asynchronously via Cumulocity’s reliable queuing mechanism. Devices execute operations and report results back, enabling consistent remote management and automation. Typical operations include installing a new firmware, switching a relay in a power meter or sending a credit to a vending machine.
The user who creates an inventory object (such as a device or a group) automatically becomes its owner. Ownership grants users full permission (ADMIN, READ, CHANGE) for that specific object to ensure that they can fully manage the resources they create.
Permissions are the most granular level of access control in Cumulocity, defining the ability to perform a specific action (for example, READ, CREATE, ADMIN) on a particular type of data (for example, alarms, inventory). Permissions are not assigned to users directly. Instead, they are grouped into roles.
Private Preview denotes a feature release stage in the Continuous Deployment model where a new feature is made available to a limited, invitation-only group of selected customers for feedback and testing. See also, Public Preview and General Availability.
The processing mode is a mechanism that allows clients to control how Cumulocity handles incoming data (measurements and events) with respect to data persistence and real-time processing. Modes include: PERSISTENT (default), TRANSIENT (process, don’t store), QUIESCENT (store, suppress notifications), and CEP (process transiently, suppress notifications).
Public Preview denotes a feature release stage in the Continuous Deployment model where a new feature is made available to any customer who opts in to use it. Features in this stage are not yet considered generally available. See also, Private Preview and General Availability.
RBAC (Role-Based Access Control) is a security model used by Cumulocity in which permissions are grouped into roles, and these roles are then assigned to users or user groups. This allows administrators to manage access based on a user’s function or responsibilities.
Release notes are published for each Cumulocity Yearly release and its subsequent maintenance releases, detailing new features, bug fixes, and API changes. Release notes help users track changes and understand their impact on deployments.
Reports are global dashboards, accessible in the Cockpit application, and visible across the entire tenant regardless of the asset hierarchy. A report serves as a customizable container for widgets to visualize and track tenant-wide data like applications, alarms, and assets.
The Cumulocity REST API is an interface that allows for communication between the Cumulocity platform and other systems via HTTP and REST.
See the Cumulocity OpenAPI Specification.
Roles are named collections of permissions that can be assigned to users and/or devices to determine the level of authorization on the platform. Roles are the central component of Cumulocity’s RBAC model. The platform distinguishes between global roles (tenant-wide) and inventory roles (specific to the device data in the inventory).
A service user is a non-human user account that is created automatically when a tenant subscribes to a microservice. It allows the microservice to interact with the tenant’s data via the REST API for background tasks, independent of any end-user’s session.
Smart groups are groups whose membership is dynamically determined based on device properties matching defined criteria, rather than static assignment. This is a feature of the Device Management application.
SmartREST is a lightweight, CSV-based device protocol to exchange data between devices and the platform. SmartREST uses standard MQTT. The protocol enables devices to send and receive structured messages using templates that map message fields to object properties, reducing the message size and simplifying the integration for resource-constrained IoT devices.
SSO (Single sign-on) is an authentication method that allows users to log into Cumulocity using credentials from an external, third-party identity provider (IdP) that supports the OAuth2 protocol, such as Azure AD.
A standard tenant is a tenant that does not have tenant management capabilities. Unlike an Enterprise tenant or Management tenant, a Standard tenant lacks multi-tenancy features and cannot create subtenants.
A subtenant is a tenant created and managed under a parent tenant (either an Enterprise tenant or the Management tenant) within the Cumulocity tenant hierarchy.
A tenant represents a logically isolated data space within Cumulocity, typically corresponding to a customer or organizational unit. It has its own users, devices, applications, and data.
The tenant domain refers to the domain name used to access a Cumulocity tenant, in the format <tenant-name\>.\<instance-name\>. It is used for login and API access and is distinct from the tenant’s unique identifier (tenant ID). For example, a tenant named “acme” on the instance cumulocity.com would have the tenant domain “acme.cumulocity.com”. Enterprise tenants and their subtenants can optionally configure custom domains for access using the platform’s custom domain feature.
The tenant hierachy refers to the structure organizing tenants in Cumulocity, involving a Management tenant at the top, Enterprise tenants below it, and Standard tenants at the lowest level.
For details, see Tenant hierarchy in the documentation.
A tenant ID is a unique identifier assigned to each tenant. The tenant ID is often used as a prefix in the username for authentication (for example, \<tenantID\>/\<username\>).
Tenant options are configurable key-value pairs associated with a tenant, used to customize platform behavior, application settings, or store tenant-specific configurations.
Tenant policies are predefined sets of tenant options and retention rules that can be created in a Management tenant or Enterprise tenant and applied when creating new subtenants to ensure consistent initial configurations.
The official online forum and knowledge base for Cumulocity users and developers to ask questions, share solutions, find tutorials, and stay updated on platform news and events. See https://community.cumulocity.com/.
Thick Edge is an informal term for Cumulocity Edge, see Cumulocity Edge.
Thin-edge.io is an open-source software framework recommended by Cumulocity for custom device integration. It provides components and tools to connect devices to the platform, particularly suitable for implementing device-side logic.
An individual account within a Cumulocity tenant, identified by a unique username. Users are assigned roles and permissions that determine their access rights to data and functionalities.
An optional feature allowing the creation of hierarchical relationships between users. This enables parent users to manage their sub-users and delegate permissions.
A Cumulocity web application is a browser-based application hosted on the Cumulocity platform. This includes the official Cumulocity applications (such as Cockpit, Device Management, Administration, and Streaming Analytics), as well as custom applications built by customers, optionally using the Cumulocity Web SDK.
The Cumulocity Web SDK is a development framework that enables users to build extensions or web applications for deployment on the Cumulocity platform. It provides secure API access, access to default UI components, and support for custom branding, allowing developers to create tailored applications that seamlessly integrate with the platform’s ecosystem and maintain a consistent user experience.
A widget is a configurable UI component that can be added to a Cumulocity dashboard to visualize IoT data. Widgets can display maps, images, graphs, tables, and other information such as alarms, measurements, and events.
In Analytics Builder, wires are used to connect two or more blocks with each other for data transfer between the output port of one block and the input port of another block.
Yearly releases are provided in a yearly cycle and named after the year, for example, Cumulocity 2025 release. The General Availability (GA) for a Yearly release is scheduled for the 31st of March of the respective year. See also, Continous Deployment model.